1. Field of the Invention
The present invention is related to conversion systems and methods between CORBA and C/C++ architectures, and more particularly, to conversion systems and methods between CORBA and C/C++ architectures for CORBA data structure types called data pairs or couples.
2. Background of the Related Art
A widely used distributed system standard is the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA). With respect to heterogeneity, for example, programmers can hide details of the underlying hardware and system software behind a portable interface, using CORBA's Interface Definition Language (IDL).
IDL is a declarative language that is independent of the target programming language and operation system. It allows CORBA objects to invoke operations on each other even when implemented in different languages and even when running on incompatible operating systems.
Wrapper objects and Object Request Broker (ORB) gateways enable interoperability by letting programmers interface new technology to legacy information systems. CORBA supports the development of highly modular applications, so programmers can more easily achieve extensibility--as well as better maintainability.
However, neither CORBA nor the complementary OMG Common Object Services Specification adequately addresses availability and reliability. CORBA does not support the dynamic replication of object implementations and cannot consistently detect partial failures in a distributed application. See, for example, Silvano Maffeis, Piranha: A COBRA Tool for High Availability, IEEE COMPUTER 59 (April 1997), incorporated herein by reference.
CORBA is emerging as an architectural standard within the call center environments. Integration between CORBA and standard C/C++ environments is an issue that all integrators in the call center business face. In CORBA, a type is an identifiable entity with an associated predicate (a single-argument mathematical function with a boolean result) defined over values. A value satisfies a type if the predicate is true for that value. A value that satisfies a type is generally called a member of the type.
The following is a description on constraints on the data types:
Basic type
16-bit and 32-bit signed and unsigned 2's complement integers PA1 32-bit and 64-bit IEEE floating point numbers PA1 Characters, as defined in ISO Latin-1 (8859.1) PA1 A boolean type taking the values TRUE and FALSE PA1 An 8-bit opaque datatype, guaranteed to not undergo any conversion during transfer between systems PA1 Enumerated types consisting of ordered sequences of identifiers PA1 A string type which consists of a variable-length array of characters; the length of the string is available at runtime. PA1 A type "any" which can represent any possible basic or constructed type PA1 A record type (called struct), consisting of an ordered set of (name, value) pairs PA1 A discriminated union type, consisting of a discriminator followed by an instance of a type appropriate to the discriminator value PA1 A sequence type which consists of a variable-length array of a single type; the length of the sequence is available at runtime PA1 An array type which consists of a fixed-length array of a single type PA1 An interface type, which specifies the set of operations which an instance of that type must support Values in a request are restricted to values that satisfy these type constraints. The legal values of types are shown in FIG. 1. PA1 1. The distributed processing environment. PA1 2. Most organizations having a variety of brands of server and client machines with different processors (CPU's) and operating systems. We have determined, however, that it is desirable to develop a value pair encoder, decoder system (or converter). We have realized that the converter system should meet the following design criteria: PA1 1. Transparent to the client programmer, PA1 2. Flexible enough to support different memory structures, PA1 3. Portable so different hardware platforms and operating systems can be supported, and PA1 4. Fast.
Constructed types
The CORBA architecture presents a relatively new data structure type called the record type, or more commonly known as data pairs or couples. In this architecture, a data pair contains two linked objects; a name and a value. Information in these pairs is stored as variable length strings. Grouped data objects can also be represented by this name/value coupling of the CORBA as a sequence of value pairs.
This grouping of names and values into a sequence of couples is similar to the structures used in C/C++ to group data. These structures can contain not only variable length strings (as CORBA is limited to), but, we have realized, can also include any basic data type defined by ANSI for the C/C++ languages.
The application programmer, who works with these two environments (i.e., CORBA and C/C++) faces the problem of converting information between these two data storage methods. Accordingly, we have identified the need for transparent conversion routines between the two environments of the CORBA to conventional C/C++ data structure converter (hereafter referred to as "the converter").
Since CORBA is a relatively new technology for the industry, there is no known solution to this conversion problem. Usually the solution is up to the capacity of the programmer and the specifics of the problem being dealt with on the particular project. For example, the following is a discussion of standard schemes used to convert between CORBA and the C/C++ environments.
Examples of the basic data types having the mappings between CORBA and C are shown in Table 1 below. Implementations are responsible for providing typedefs for CORBA.sub.-- short, CORBA.sub.-- long, and so forth, consistent with standard CORBA requirements for the corresponding data types.
TABLE 1 ______________________________________ CORBA C ______________________________________ short CORBA.sub.-- short long CORBA.sub.-- long unsigned short CORBA.sub.-- unsigned.sub.-- short unsigned long CORBA.sub.-- unsigned.sub.-- long float CORBA.sub.-- float double CORBA.sub.-- double char CORBA.sub.-- char boolean CORBA.sub.-- boolean octet CORBA.sub.-- octet ______________________________________
The C mapping of the boolean types is, for example, unsigned char with only the values 1 (TRUE) and 0 (FALSE) defined. CORBA.sub.-- boolean is provided for symmetry with the other basic data type mappings.
Examples of the basic data types having the mappings between CORBA and C++ are shown in Table 2 below. The mapping of the boolean type defines, for example, only the values 1 (TRUE) and 0 (FALSE).
TABLE 2 ______________________________________ CORBA C++ ______________________________________ short CORBA::Short long CORBA::Long unsigned short CORBA::UShort unsigned long CORBA::ULong float CORBA::Float double CORBA::Double char CORBA::Char boolean CORBA::Boolean octet CORBA::Octet ______________________________________
Each basic type is mapped to a typedef in the CORBA module. This is because some types, such as short and long, may have different representations on different platforms, and the CORBA definitions will reflect the appropriate representation. For example, on a 64-bit machine where a long integer is 64 bits, the definition of CORBA::Long would still refer to a 32-bit integer.
Except for boolean, char, and octet, the mappings for basic types must be distinguishable from each other for the purposes of overloading. That is, one can safely write overloaded C++ functions on Short, UShort, Long, ULong, Float, and Double.
Thus, the existing conversion techniques focus on, or involve, predetermined mappings that may not be suitable for specific hardware and/or operating system environments. Further, with respect to converting couples or data pairs, this conversion process in a software client environment is almost impossible for two reasons:
We have also realized that this conversion process should performed in a general purpose way, meaning the mapping of information can be changed by modifications to an initialization file. In this connection, we have realized that it is desirable that the mapping of information does not require changing the converter software each time to add, change or remove translations.
We have further determined that it is desirable that the conversions are performed in a manner to hide structure alignment issues from the client.
We have also realized that this conversion process needs to be evaluated individually and converted according to the alignment and size of the hardware, and also needs to be transmitted to the server in a C/C++ style message structure.
We have also realized that it is desirable to eliminate the need for client programs and programmers to know the hardware and software characteristics of a corresponding server.